Generally, this invention relates to computer systems and more particularly to input/output (I/O) devices.
As is known in the art, computer systems include at least one central processing unit (CPU) and a memory system. A computer also includes a set of signal lines commonly referred to as a bus. The bus carries address, data, and control information to and from the CPU. The CPU executes instructions fetched from the memory to provide central control for the computer. Generally, the CPU sends and receives data via the bus from external devices commonly referred to as peripheral devices.
An input/output (I/O) interface device or module is generally coupled to the bus and is used to interface the bus and hence the CPU to the external devices, thereby facilitating communication between the CPU and the external devices. Examples of external devices include peripheral devices such as disk drives, tape drives, and printers. The I/O module includes circuits to effect the transfer of data between the CPU and external devices. Amongst these circuits are so called external device controllers, each of which is responsible for controlling the transfer of data between the I/O module and an external device. A device controller includes inter alia a processing unit and a bank of storage registers commonly referred to as control and status registers (CSRs) which are used by the device controller and the CPU for data manipulation and, peripheral device and device controller status reporting.
The individual device controllers execute software instructions stored in the random access memory which is typically resident on the I/O module. The software instructions are executed by the device controllers to transfer the data between the external devices and CPU when a request for data transfer is requested by the CPU. In normal operation, the CPU would perform a read data or write data operation to an external device by addressing a control and status register (CSR) within the appropriate controller for the external device. After addressing the particular controller's CSR, the CPU would write data into the addressed CSR instructing the controller as to the location in memory of the software instructions which need to be executed to accomplish the read or write operation.
In order to accomplish a read or write operation, it is often necessary for a controller to move or access data within its own bank of CSRs. There are commercially available controllers which allow for direct access of CSRs via an internal data path i.e., they are able to access their own CSRs without an external bus cycle. However, controllers are often designed which are not capable of accessing their own CSRs directly. For the latter type of controller it is therefore necessary for the controller to address itself in the same manner in which it would address memory locations not located within the controller (i.e. using an external bus cycle). For controllers which require an external bus cycle to access their own CSRs, the controller places an address on the bus including bits of address data indicating which memory space it needs to access, which controller chip it needs to access, and which CSR within the controller chip it needs to access. There are different approaches used to decode the address placed on the bus by the controller. One approach uses address decode logic which is incorporated into the controller. The address decode logic allows the controller to sense the address on the bus as being one indicating a destination within the range of its own CSRs. A second approach requires the use of separate address decode logic to decipher the address and generate a chip select to the appropriate controller. In both cases, each individual CSR within each controller must be assigned a unique address and to access any CSR requires placing that unique address on the bus. As a result, the software instructions which cause a controller to access its own CSRs contains the full address of the CSR including the address of the particular controller.
One problem with the above mentioned addressing scheme is that it precludes two similar controllers performing similar operations (i.e. accessing the same CSR within their respective bank of CSRs) from using the same software instruction to accomplish the operation. This occurs because software instructions executed by a controller which cause it to access its own CSRs will contain the full address of the CSR including the address of the controller. Thus, in order for a controller to access its own CSRs it is necessary to imbed the address of the controller within the software instruction that causes the controller to access its own CSRs. Two different controllers therefore can not use that instruction and hence can not use a common set of instructions for the same operations.
As an example of the effect of this problem, a software instruction which causes a first controller to access data located in a CSR located within the first controller, is not useable to cause a second controller to access data in a corresponding CSR located within the second controller. To overcome this problem requires that for each of these potential disparities, the affected software must be replicated for each controller. For an I/O module having several controllers, this replication requires a large amount of random access memory to store the replicated software instructions.